Configuring device and application settings across a number of devices in an enterprise setting can be cumbersome and inefficient. Typically, an administrator within an enterprise uses a Mobile Device Management (“MDM”) or Enterprise Mobility Management (“EMM”) system (collectively, “EMM systems”) to support and configure devices across an enterprise.
Historically, application developers created custom software development kits (“SDKs”) to enable configuration of their applications through EMM systems. While these SDKs provide access to configuration and management features, they also require time-consuming work on the EMM-provider side to adapt an EMM system such that it can configure the customized aspects provided by the SDK.
More recently, some application developers and original equipment manufacturers (“OEMs”) have begun using application-configuration (“app-config”) applications that standardize certain actions across different types of devices. For example, a company such as SAMSUNG can release an app-config application that allows an EMM system to configure certain features on a SAMSUNG device, such as restricting camera access based on the device's geographic location. The EMM system can instruct the app-config application on the device to implement settings made available by the application. Because the configuration options can be standardized across different devices and OEMs, the configuration process on the EMM-provider side can be substantially streamlined. The EMM provider can obtain a blueprint, or “schema file,” containing the various configuration options available in a particular app-config application. This can allow the EMM provider to design an interface that an administrator can use to view and select the available configurations.
App-config applications continue to grow in complexity, presenting new workflow problems for EMM providers attempting to access the various configuration options. For example, newer app-config applications provide options for complex or nested configurations. These configurations can have one or more levels, with each level including more granular detail that is “nested” within a broader configuration option. Existing workflows do not provide the flexibility to allow an administrator to take advantage of these nested options. Additionally, the existing workflows lack adequate extensibility, requiring extensive reworking when newer, deeper configuration options are released by an OEM or developer.
As a result, a need exists for an improved interface for configuring devices, such as by supporting complex arrays in a data-driven user interface (“DDUI” or “GUI”).